Go Down

Topic: Robot Navigation System- Urgent (Read 5830 times) previous topic - next topic

Ashrah

Dear all,

I am currently working on my senior graduation project, and I really need your help urgently. my team and I are working on Electric wheel chair using Meccanum wheels that will be used mainly in hospitals and industries. it mainly rains over 4 separated wheels with 4 separated Separately excited motors 1 for each and 2 24 voltage batteries and 4 separated drivers. We are also using 2 microcontrolers; Arduino uno and Leonardo. I was able to implement the Voice recognition system to be able to direct the robot throughout direct commands as right and left ...etc.

I am stuck now with the Navigation systems. what I need to be done is he following:

- inserting a detailed room map to be able to determine exact locations; for example when I say " Bathroom " the arduino will automatically change the word to its saved location on the map as {X,Y} coordinates.
- receive the current robot's location from the encoders and convert it onto  {X,Y} coordinates.
- the arduino should draw the path to be followed to reach that point. The collision avoidance mechanism is already done.

Please help me with the code that I can implement, I am really lost guys.

Please note that I will not use any GPS devices.

Help me guys it is really urgent :D

thank you

keeper63


I am stuck now with the Navigation systems. what I need to be done is he following:

- inserting a detailed room map to be able to determine exact locations; for example when I say " Bathroom " the arduino will automatically change the word to its saved location on the map as {X,Y} coordinates.
- receive the current robot's location from the encoders and convert it onto  {X,Y} coordinates.
- the arduino should draw the path to be followed to reach that point. The collision avoidance mechanism is already done.

Please help me with the code that I can implement, I am really lost guys.

Please note that I will not use any GPS devices.

Help me guys it is really urgent :D


What you are proposing, in the real world, will not likely work. The main reason is that no sensor is perfect, and no drive system is perfect. For instance, if you placed the robot you built in some position, and called that position (in cartesian coordinates) [0,0] - and then you directed the robot to move (let's say in meters) forward to [0,10] then right to [10,10], then move diagonally back to your start point of [0,0] - even if there were no obstacles in the way, you would not arrive exactly back where you started, even if you carefully controlled everything. If you told the robot to repeat this motion, the error drift of the system would be such that after only a few iterations, your robot would be no where near it's original starting point.

This is reality. What you are attempting to do is called "localization" - basically getting your robot to navigate in a fairly unfamiliar environment and "know" with a certain degree of certainty (btw - it can never be 100 percent sure - because it's sensors aren't perfect, either) where it is, compared to what it has previously learned about it's environment as it moved around and used it's sensors to build up a map of it's surroundings (and perhaps compared it to the map it had in memory).

Localization is only part of the issue - the other part is mapping, as I indicated above. This process actually has a name (well, an acronym): SLAM

http://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping

It is not an easy problem to solve - in fact, there are many "solutions" to this problem, none of them are perfect.

Fortunately, you have a platform on which you can explore this fascinating field and try out some of those solutions; you will definitely need and want that "map" (each room could be considered a "way-point" of sorts - you might want to set up other way-points as well to help the system - perhaps ones in the middle of doorways, ones along the middle of hallways, at T-junctions, etc).

This is only part of the solution, though. You need to also be able to use your sensors (hopefully, you can measure distances with these sensors?) to determine where you are, and implement a method for the robot to "take a guess" at where it likely is, based on it's last measurement(s) - as well as it's prior measurements, and also an idea of how to get closer to it's goal (one of the way-points) on it's next move.

There is also the need to do path planning (wavefront, A*, etc) - so you know what is an optimum solution to get from point A to point B.

I know all of that is fairly vague. It's a big subject, one with no optimum solution, yet. People have been researching this issue for a half century or more. All I can say is that any potential system you might make without taking something like SLAM into account is likely not to work very well at all. The only way to have any hope of it working well in some fashion (without delving deep into a SLAM solution), would be to somehow have markers or way-points (perhaps QR codes on the ceiling or floor, with a camera pointed up/down) that encode where that way-point is, how far away and in what direction other way-points lie, and to utilize the orientation of the way-point QR code (that is, how much it is rotated when the camera images it) in a way to indicate in what direction the robot is facing when it scanned the QR code way-point.

Another potential solution would be to use some kind of "digital paper" pattern for the floor:

http://en.wikipedia.org/wiki/Digital_paper

With this, and the right software, your robot could know exactly where it is in a building, and what direction it is facing. It's kinda like a pre-computed SLAM system, in a manner of speaking.

None of these solutions have an easy implementation, and I doubt you are going to get anyone writing you a set of code to implement a naive system (which will likely ultimately fail - then again, if this isn't an issue - that you just need something that appears like it could work, at least in a controlled setting, then maybe naive code will be ok).

If you are really interested in learning about SLAM (and other techniques for autonomous driving/navigation) - I encourage you to take this free online course:

https://www.udacity.com/course/cs373

...now as far as a naive system - here's what you could potentially try:

1. Build a map of way-point vector coordinates on your map, using whatever you wish to denote units; you will need one per room (center of room, or whatever is convenient or best) - but you will also want coordinates along hallways, at T-junctions, in doorways, etc.

2. For each path from one way-point to the next, you will need to build a list (a linked list would work well) of way-point vectors to designate the paths. Remember that paths are 2-way; you may want to have "common paths" along hallways and such, and "exclusive paths" - say from hallway to door to room way-point. You could then link up these meta-path lists into larger paths, which should take up less memory. Each node in the list for the path should have some way of indicating in what direction the robot is travelling it (so it knows whether to move forward or backward in the list).

3. You may need to measure and adjust things using the ordinary cartesian distance equation; there's likely to be a bit more than usual of geometry needed to know based on what way-point you are at, and what direction you are facing, how to turn and get to the next way-point.

4. You are obviously going to need to integrate the encoder values (distance travelled) and direction facing, amount turned, etc into the system so that as you back up, turn, etc - to avoid obstacles - these take into account the needed changes in position.

Ultimately, though - even doing all of this - you are still doing "dead reckoning" - and without some kind of on-board or external means of ascertaining direction and position within the environment to a certain degree of precision, the actual position of the robot vs where the robot believes it is at (it's "belief value") will be wildly divergent in short order.
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Ashrah

Dear Cr0sh,

first of all thank you for your prompt response, appreciate it.

I have gone through your comments and Yes it is a big issue, even much bigger than I thought . I might ease up the system a bit if you can bear with me a bit, I'm still an arduino and robotics.

you first said " What you are proposing, in the real world, will not likely work. The main reason is that no sensor is perfect, and no drive system is perfect. For instance, if you placed the robot you built in some position, and called that position (in cartesian coordinates) [0,0] - and then you directed the robot to move (let's say in meters) forward to [0,10] then right to [10,10], then move diagonally back to your start point of [0,0] - even if there were no obstacles in the way, you would not arrive exactly back where you started, even if you carefully controlled everything. If you told the robot to repeat this motion, the error drift of the system would be such that after only a few iterations, your robot would be no where near it's original starting point.

This is reality. What you are attempting to do is called "localization" - basically getting your robot to navigate in a fairly unfamiliar environment and "know" with a certain degree of certainty (btw - it can never be 100 percent sure - because it's sensors aren't perfect, either) where it is, compared to what it has previously learned about it's environment as it moved around and used it's sensors to build up a map of it's surroundings (and perhaps compared it to the map it had in memory).

Localization is only part of the issue - the other part is mapping, as I indicated above. This process actually has a name (well, an acronym): SLAM "

Alright .. what if I started the map motion from its initial start point. that way, it will not need its initial starting point anymore since it did arrive to its goal, and we can reset the current location ( goal previously ) its new starting point and start again from there. that way, I will not need reading from the sensors to exactly locate my current spot as you said sensors are not perfect, and they will just focus on the collision avoidance issue.

moving on to your solutions listed below, YES, this is exactly what I wanna do .. I wanna insert a map of way points, and that I do not know how to do to be honest. I roamed the internet for solutions and I found some, but I was lost in the middle. I mean, how can I insert coordination systems anyway ?? forgive my silly questions, as I said I'm new to this :D This is port #1

I did not get exactly what u meant by #2, if you can support me with an example I would be thankful.

as for the encoders readings' integration, Im currently working on it to find a way, but I need some help if you have the time for it.

to sum, and correct me if im wrong,

- The robot starts from its initial location only.
- we will insert a map of way points ( like nodes ) consisting of sets of coordinates systems.
- The sensors will be focusing on the collision avoidance and avoiding obstacles.
- once the robot reaches its goal, the whole system would be reset to consider this new point its initial point.

would that work as implementation at first ? I will try updating it with time to solve the listed issues you previously sent.

Thank you 

drewdavis

Kind of off topic but I figured i would show you this video. It is an example of using colors to detect position.

http://www.youtube.com/watch?v=MAwwKEXn6Mk

spoth

There are a great many historical personages who have said just that, don't bother, it wouldn't likely work in the real world. And in most of these cases someone went out into the real world and found ways to make their project work. In the real world. No sensor is perfect, true, and for that matter no effector is perfect either. But the happy coincidence is that it almost never needs to be perfect. Good enough is good enough. What needs to be done is to find a way to continually alternate between repeatedly locating and re-informing the machine of where it is (with a dash of dead reckoning too perhaps), and from wherever it is redirecting it. Magnets, laser, IR, ultrasound, RFID, coloured dots, contrast lines, dog whistles, scary voices, chemotaxis (ok, i'm getting silly, but you understand my point). Whatever works, works. Since this was written in April 2013 navigation has come a long, long way. There are driverless cars that navigate autonomously now in beta testing. Listen to what people say, yes, sure. But, do your own thinking, ok, people? Don't spiral into the it-cant-work-anyway negativity.

zoomkat

Quote
There are driverless cars that navigate autonomously now in beta testing. Listen to what people say, yes, sure. But, do your own thinking, ok, people? Don't spiral into the it-cant-work-anyway negativity.
So those driverless cars use arduinos?
Google forum search: Use Google Search box in upper right side of this page.
Why I like my 2005 Rio Yellow Honda S2000  https://www.youtube.com/watch?v=pWjMvrkUqX0

Go Up