Loading ...
Sorry, an error occurred while loading the content.

re: [SeattleRobotics] Predicting Robot Position in a Differe...

Expand Messages
  • Robert Dyer
    Thanks Tom. Just a guess, but I think your method would provide substantially less accuracy than the method I m currently using due to the dead space you re
    Message 1 of 5 , Oct 16, 2013
    • 0 Attachment

      Thanks Tom.

       

      Just a guess, but I think your method would provide substantially less accuracy than the method I'm currently using due to the "dead space" you're describing. And yes, you're correct, I am using quadrature encoders. My current setup has a rotation resolution equivalent to 2mm of travel of each wheel. I'm hoping to maintain that if I can.

       

      The SPAM filter at my ISP classifies most of the emails from the SRS email list as SPAM for some reason. I forgot to delete it from the Subject line of the email before I sent the reply.

       

      Robert


      From: twcarroll@...
      Sent: Wednesday, October 16, 2013 2:42 PM
      To: SeattleRobotics@yahoogroups.com
      Subject: [SeattleRobotics] Predicting Robot Position in a Differe...

      Robert,

           I first used basic encoders, not a bi-directional, but more recently have used quardature bi-directional encoders, mainly because that was what I had on hand.  I believe that you would want bi-directional feedback, despite that fact that your microcontroller may be telling your motor drivers to go one particular direction and, therefore, you can know that you are, indeed going the way your microcontroller is telling the wheels to go.
       
           Take into consideration that, as with all casters, there is a 'dead space' for lack of a better word where the caster suddenly has to swing around because the robot is traveling in another direction. You'll lose a few inches of encoder 'ticks,' depending on the size and swing of the 'caster' / wheel / encoder assembly.
       
           Tom
       
           PS:  I see the word "SPAM" attached to this.  What gives??

      Thanks Tom,

      Do you also put an encoder on the swivel to determine the direction the trailing wheel is pointing when it sends the output ticks, or is this unnecessary?

      Robert


    • twcarroll@...
      Robert, If the encoder used for the caster was the same encoder that you have on your differentially-driven robot, the accuracy would be identical for
      Message 2 of 5 , Oct 16, 2013
      • 0 Attachment
        Robert,
             If the encoder used for the 'caster' was the same encoder that you have on your differentially-driven robot, the accuracy would be identical for straight forward travel on a smooth surface with good traction.  If you vary back and forth during your travel, it would still be identical as first right then left would average out.  If you were heading around a 'race course' where you turned the same direction each time, the caster encoder would average out the readings on the two wheel encoders, if it was placed in the center.
         
             Now, if the surface caused slippage at any location, whether straight or turning,- the caster would give you much better readings. The slippage could be one or two wheels slipping and going faster than travel, or slippage if the robot happened to move and the wheels were NOT moving, like accidentally slipping down a slope when the robot was trying not to move. In these cases, the caster encoder would tell the microcontroller that the robot had moved. I have seen many robots that used this method in conjunction with a micro-gyro or compass to verify correct odometry as well as direction of travel and degrees of turning.
         
             Tom C
        Just a guess, but I think your method would provide substantially less accuracy than the method I'm currently using due to the "dead space" you're describing. And yes, you're correct, I am using quadrature encoders. My current setup has a rotation resolution equivalent to 2mm of travel of each wheel. I'm hoping to maintain that if I can.
      • Robert Dyer
        Hey Tom, I definitely agree that for straight-line motion where wheel slippage is the error issue, a trailing, no-friction caster is superior. I ll have to
        Message 3 of 5 , Oct 17, 2013
        • 0 Attachment

          Hey Tom,

           

          I definitely agree that for straight-line motion where wheel slippage is the error issue, a trailing, no-friction caster is superior.

           

          I'll have to think about this more, but in any turn doesn't the encoder actually measure robot movement distance multiplied by the cosine of the angle between the robot direction and the caster direction? And again in the limiting case, if I'm making a sharp turn where the robot isn't moving forward at all, but just pivoting on its own axis, wouldn't the the angle of the caster be perpendicular to the forward direction of the robot (cosine=0), and won't the caster increase encoder counts without true movement of the robot? That's why I think this scheme would require a separate encoder on the caster swivel.

           

          For most "close-to-straight-line" movements the "error angle" would be small and the cosine close to 1.000. But for turns it seems like it won't be as accurate - the sharper the turn the less accurate. Unfortunately that's what I'm already facing now that I'm already working with the wheel slippage error.

           

          Robert


          From: twcarroll@...
          Sent: Wednesday, October 16, 2013 4:13 PM
          To: SeattleRobotics@yahoogroups.com
          Subject: [***SPAM***] Re: [SeattleRobotics] Predicting Robot Position in a Differe... 

          Robert,

               If the encoder used for the 'caster' was the same encoder that you have on your differentially-driven robot, the accuracy would be identical for straight forward travel on a smooth surface with good traction.  If you vary back and forth during your travel, it would still be identical as first right then left would average out.  If you were heading around a 'race course' where you turned the same direction each time, the caster encoder would average out the readings on the two wheel encoders, if it was placed in the center.
           
               Now, if the surface caused slippage at any location, whether straight or turning,- the caster would give you much better readings. The slippage could be one or two wheels slipping and going faster than travel, or slippage if the robot happened to move and the wheels were NOT moving, like accidentally slipping down a slope when the robot was trying not to move. In these cases, the caster encoder would tell the microcontroller that the robot had moved. I have seen many robots that used this method in conjunction with a micro-gyro or compass to verify correct odometry as well as direction of travel and degrees of turning.
           
               Tom C
          Just a guess, but I think your method would provide substantially less accuracy than the method I'm currently using due to the "dead space" you're describing. And yes, you're correct, I am using quadrature encoders. My current setup has a rotation resolution equivalent to 2mm of travel of each wheel. I'm hoping to maintain that if I can.

        • Charlie H
          Tom, I ve often thought of implementing an alternate means of measuring movement. But rather than an encoder attached to a caster I ve been thinking of
          Message 4 of 5 , Oct 17, 2013
          • 0 Attachment
            Tom,

            I've often thought of implementing an alternate means of measuring movement.  But rather than an encoder attached to a caster I've been thinking of suspending a computer mouse below the robot and letting the ball contact the floor.  If the ball was on the axle line between the wheels it would only measure fore and aft movement of the robot.  Therefore I would mount it behind the axle line, perhaps midway between the axle and the caster, to also detect rotation of the robot.  With a little trig one could work out both rotation and translation of the robot to provide heading and distance traveled.

            Charlie

            On 10/16/2013 7:13 PM, twcarroll@... wrote:
             

            Robert,
                 If the encoder used for the 'caster' was the same encoder that you have on your differentially-driven robot, the accuracy would be identical for straight forward travel on a smooth surface with good traction.  If you vary back and forth during your travel, it would still be identical as first right then left would average out.  If you were heading around a 'race course' where you turned the same direction each time, the caster encoder would average out the readings on the two wheel encoders, if it was placed in the center.
             
                 Now, if the surface caused slippage at any location, whether straight or turning,- the caster would give you much better readings. The slippage could be one or two wheels slipping and going faster than travel, or slippage if the robot happened to move and the wheels were NOT moving, like accidentally slipping down a slope when the robot was trying not to move. In these cases, the caster encoder would tell the microcontroller that the robot had moved. I have seen many robots that used this method in conjunction with a micro-gyro or compass to verify correct odometry as well as direction of travel and degrees of turning.
             
                 Tom C
            Just a guess, but I think your method would provide substantially less accuracy than the method I'm currently using due to the "dead space" you're describing. And yes, you're correct, I am using quadrature encoders. My current setup has a rotation resolution equivalent to 2mm of travel of each wheel. I'm hoping to maintain that if I can.

          • Robert Dyer
            Charlie, For a brief time Parallax had a mouse sensor kit available. It was based on an optical mouse sensor, but it s recently been discontinued. It was very
            Message 5 of 5 , Oct 17, 2013
            • 0 Attachment
              Charlie,

              For a brief time Parallax had a mouse sensor kit available. It was based on
              an optical mouse sensor, but it's recently been discontinued. It was very
              inconsistent - missing a lot of movement. I think that's why it may have
              been discontinued.

              I tried several different printed backgrounds. The best was a 50% black
              hashed background. But even then it didn't report a lot of movement. I
              think a mouse works fine when it has direct human feedback, because if it
              doesn't move far enough you can always move it further and adjust it based
              on what you see on the screen. But for a robot it just didn't work.

              I too think it's a great idea. I wish it worked!

              Robert

              Sent fm my iPhone
              --------------Original Message--------------

              From: Charlie H <carlosh1@...>
              Sent: Thursday, October 17, 2013 10:34:AM
              To: SeattleRobotics@yahoogroups.com
              Subject: [***SPAM***] Re: [SeattleRobotics] Predicting Robot Position in a
              Differe...

              Tom,

              I've often thought of implementing an alternate means of measuring
              movement. But rather than an encoder attached to a caster I've been
              thinking of suspending a computer mouse below the robot and letting the
              ball contact the floor. If the ball was on the axle line between the
              wheels it would only measure fore and aft movement of the robot.
              Therefore I would mount it behind the axle line, perhaps midway between
              the axle and the caster, to also detect rotation of the robot. With a
              little trig one could work out both rotation and translation of the
              robot to provide heading and distance traveled.

              Charlie

              On 10/16/2013 7:13 PM, twcarroll@... wrote:
              >
              > *Robert,*
              > If the encoder used for the 'caster' was the same encoder that
              > you have on your differentially-driven robot, the accuracy would be
              > identical for straight forward travel on a smooth surface with good
              > traction. If you vary back and forth during your travel, it would
              > still be identical as first right then left would average out. If you
              > were heading around a 'race course' where you turned the same
              > direction each time, the caster encoder would average out the readings
              > on the two wheel encoders, if it was placed in the center.
              > Now, if the surface caused slippage at any location, whether
              > straight or turning,- the caster would give you much better
              > readings. The slippage could be one or two wheels slipping and going
              > faster than travel, or slippage if the robot happened to move and the
              > wheels were NOT moving, like accidentally slipping down a slope when
              > the robot was trying not to move. In these cases, the caster encoder
              > would tell the microcontroller that the robot had moved. I have seen
              > many robots that used this method in conjunction with a micro-gyro or
              > compass to verify correct odometry as well as direction of travel and
              > degrees of turning.
              > * Tom C*
              >
              > Just a guess, but I think your method would provide substantially
              > less accuracy than the method I'm currently using due to the "dead
              > space" you're describing. And yes, you're correct, I am using
              > quadrature encoders. My current setup has a rotation resolution
              > equivalent to 2mm of travel of each wheel. I'm hoping to maintain
              > that if I can.
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.