An area which is puzzling me is how a robot can know where it is relative to another location. I mission a robot to travel 20 feet straight ahead, avoiding objects in the way. In the simplest case, how do I know I have travelled 20 feet. Wheel encoders are not allowed. :o
I plan on having a distance sensor on a servo that can scan the field ahead and to the sides.
My first though was GPS. But, I don’t think most GPS systems do not have the gradularity needed for short trips (10-20 feet).
With a bit of trig I can see how to navigate if there are one or more fixed object visible on the way to a destination, using a distance sensor. I can use these objects as benchmarks.
I suspect that an accelerometer and compass maybe the answer? ???
Any special reason for “Wheel encoders are not allowed” ? is this for a contest of some sort?
If you can’t use encoders I would go with stepper motors.
And you say “Hit something and you are lost?”, -thats what sensors are for
The simple way would be to determine how long it take you to travel 1 foot at a set acceleration. Handling slipage in this case can be done with a acceleration sensor to determine if you are actually moving or are stalled.
If you need me to give you a more anal explanation let me know. I would personally use motor shaft encoders and a acceleration sensor to detect stall. On thing i have learned is to have a backup for your backup. Of course i build mainly competition robots so failure is a option i would rather not have.
If you are using tracks you might think about having the encoder markings on the tracks them self?
I have never worked with acceleration sensors, but wont the acceleration go back to zero when the robot is moving on a steady speed? :-[
[quote]
I have never worked with acceleration sensors, but wont the acceleration go back to zero when the robot is moving on a steady speed? [/quote]
If it goes to 0 you stopped moving. While moving gravity will always have a effect and that is what is measured by a acceleration sensor.
Of course 0 will never happen as gravity always has a effect you need to find dead center of g on your sensor to know what 0 really is.
I want to clarify. If you use a acceleration sensor alone you will have error rate issues due to gravity itself. if you use encoders by itself you can a have issues with slipage and a couple other things. Using 2 or more things can help you determine each devices error states and correct for them. Not including going through slopes and so on.
I have been thinking about the same thing for a long time.
I’m planning to use wheel encoders on tracks. Moving in a straight line with encoders and track shouldn’t be a problem regarding slipping.
The problem will be during turning when the tracks them selfs are forced to slide on the floor and you can’t tell if one track is slipping more than the other.
My idea is to use a compass module to make turing more acurate. Of course magnets in the area will be problematic, but it should be possible to take that into account.
The problem I have with G sensors(I think it’s a problem anyway) is that you need really expensive G sensors with very little noise else drift becomes a problem.
You have to integrate the G to get speed.
Then you have to integrate the speed to get distance.
A small offset in G will, over time, give you a big speed/distance error.
This means that you have to reset it regularly to a known value.
Regarding navigation.
I have seen references to modules that you place on a robot and put a “constalation” on the ceiling. Then it uses a camera to look at the markers to determine it’s location.
SLAM short cut for “Simultaneous localization and mapping” is the key to get the position of a robot. Using odometry data to get the distance the robot moved and verify the result with landmarks given by the distance data of range sensors.
Here is a good writeup about SLAM called SLAM for Dummys
In a perfect world. If you know your exact compass direction and your wheel rotations, then you are almost an on-board gps if you know your starting point. As others say, things like slippage and environment play havoc. So you then need to blend in other inputs from sensors to re-zero and est location. However in a gps sense, the combined error of slippage/skipage would be real difficult to account for and know for sure. MS has a research project going that attempts gps-style location without a gps using motion and other combined inputs that sounds interesting, I will try to find the link.
Wondering if you could use multiple distance sensors, like IRs, mounted facing the sides. To get your speed, assuming there are items that can be “sensored”, you could see how long it took for an item to go from sensor A to sensor B.
