go_away

Author Topic: Calculate robot movement with/without encoders/Using objects as references/SLAM  (Read 2763 times)

0 Members and 1 Guest are viewing this topic.

Offline corrado33Topic starter

  • Supreme Robot
  • *****
  • Posts: 611
  • Helpful? 11
Hey guys.  So, I've decided that my robot needs to be able to calculate how far it's moved.  I'm thinking of doing this one of two ways.  

The first way is with what is essentially a caster.  Like the one in this picture.



The caster has two measurable degrees of rotation.  First is the wheel turning.  Second is the caster spinning.  Both of these would be measured by an encoder.  I know the basics of how encoders work.  But there are a few things I'm not quite sure on.  Here goes...

Is it possible to determine direction of spin using an encoder?  
Is it possible to instead of count pulses, to maybe output an analog signal, so that I know exactly where which way the caster is pointing at all times?  Because if it only counts pulses, then if the caster reverses direction, I'm not going to know.  Maybe I could do this with a sensor that has color specificity, so I could have a color scale on my encoder wheel and the different  colors would stand for different directions.  (Maybe not color, just different shades of grey.)  I know that EM radiation (visible/IR/UV) will reflect differently depending on the color of the object(duh... that's where color comes from), and I remember reading about it, but I forget what sensor you guys said to use.  (I'll search as soon as I'm done writing this)

This was my initial plan. Could I get something like this to work?

My second plan is basically software based.  So I have IR sensors on my robot.  (I know about SLAM, but that's not exactly what I'm looking for, not yet at least.)  So let's say I wanted to move .5 meters to the right.  My robot would look left and right.  And if it saw an object to the left, it'd move to the right until that object was exactly .5 meters MORE to the left.  Exactly opposite for an object on the right.  Of course it'd use it's front and back sensors to (hopefully) keep it in a straight line.  (Parallel to something it sees etc)

Basically I'm doing this because I want to set up mapping on my robot.  I ran a program (on the computer) that moved the robot randomly, and it took something like 13000 moves to get within 90% accuracy of a 50x50 room.  (That's a heck of a lot of moves, About 36 hours to scan the room (assuming 10 seconds per move))  

So instead of moving randomly, I want to navigate myself back to a certain corner (easy enough).  Then I want to move all of the way north.  Then move one "block" over, then move all of the way south.  Then move one "block" over, then move all of the way north.  Kind of like a snake.  Of course, the "move all of the way north/south" would be accomplished by a wavefront algorithm.  

I know this is possible, but there are problems with it. (Only one I can think of now)  

First off, if nothing is seen, how can it know how far to go?  My solution:  If you wanted to move right, move left until you see something that you've seen before.  Then start moving right, calculate how fast you're moving away from that object, then calculate how long you have to move to get to the position you want to get to.  Of course, this is going to be a little inaccurate.
Or I could simply move to something I've seen before, (in any direction) then use trig to figure out how far and how long I have to travel at a given speed.  Same problems here.  

Ok, I think I'm done ranting here.  Any suggestions?


EDIT: I just realized this would probably be better in the software thread.  Admin, feel free to move it.
« Last Edit: November 09, 2009, 01:18:43 PM by corrado33 »

Offline chelmi

  • Supreme Robot
  • *****
  • Posts: 496
  • Helpful? 15
answer to your first question: google quadrature encorders

Are you building a differential drive robot ? I this is the case, put the encoders on the driving wheels. This will be a lot simpler to compute trajectory this way.

Chelmi.

Offline corrado33Topic starter

  • Supreme Robot
  • *****
  • Posts: 611
  • Helpful? 11
See, the thing is I'm building an omni bot, or else I'd simply put encoders on the wheels.  I don't know if it'll be accurate to simply rely on wheel encoders for omni wheeled robots, as the wheels spin differently on different surfaces to achieve the same velocity in a certain direction.

Offline Soeren

  • Supreme Robot
  • *****
  • Posts: 4,672
  • Helpful? 227
  • Mind Reading: 0.0
Hi,


Encoders on the wheels are prone to slippage. The caster with a wheel is the only sure way to go, if held down with a spring or similar, it wont slip (as it's not driven).
To get the heading, use an absolute position encoder.
Regards,
Søren

A rather fast and fairly heavy robot with quite large wheels needs what? A lot of power?
Please remember...
Engineering is based on numbers - not adjectives

Offline corrado33Topic starter

  • Supreme Robot
  • *****
  • Posts: 611
  • Helpful? 11
Encoders on the wheels are prone to slippage. The caster with a wheel is the only sure way to go, if held down with a spring or similar, it wont slip (as it's not driven).
To get the heading, use an absolute position encoder.

Thanks soeren!  I was planning on holding it down with some sort of suspension . 

 


Get Your Ad Here

data_list