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

Re: [SeattleRobotics] Re: Accurate odometry

Expand Messages
  • Peter Balch
    From: Alan ... Not sure what you mean. A pass by the Target happens when the buggy gets within 20 pixels. The target then jumps to somewhere else on the
    Message 1 of 23 , Jan 1, 2012
    View Source
    • 0 Attachment
      From: Alan
      > > It's called Buggy.zip
      > > It doesn't seem to have appeared yet so here it is on my website:
      > > http://www.peterbalch.btinternet.co.uk/buggy.htm
      > What is the criteria for a good pass-by? Maybe add a "hits" counter? Just
      > a thought.

      Not sure what you mean. A pass by the Target happens when the buggy gets
      within 20 pixels. The target then jumps to somewhere else on the screen.

      It's rather reminiscent of the way navigation works in Bamzooki
      http://www.bbc.co.uk/cbbc/bamzooki/

      Bamzooki is intriguing for those of us who are interested in robot
      user-interfaces (i.e. just me AFAIK), It's meant for small children to be
      able to create legged robots and then to have them navigate. The interesting
      thing about the user-interface for describing gaits is that it doesn't
      exist. A child can stick random legs on and the program will steer the
      resulting robot towards successive waypoints by walking harder on one side.
      I think the program knows how to "walk" by recognising the class of legs
      used but I don't know how it coordinates the phases of legs on different
      segments.

      Peter
    • KM6VV
      That answers it, within 20 pixels. Interesting simulation! You must have a simulation engine or similar to write all your simulations. C language, I
      Message 2 of 23 , Jan 1, 2012
      View Source
      • 0 Attachment
        That answers it, within 20 pixels.

        Interesting simulation!

        You must have a "simulation engine" or similar to write all your
        simulations. C language, I presume?

        Alan KM6VV

        On 1/1/2012 12:58 PM, Peter Balch wrote:
        > From: Alan
        >>> It's called Buggy.zip
        >>> It doesn't seem to have appeared yet so here it is on my website:
        >>> http://www.peterbalch.btinternet.co.uk/buggy.htm
        >> What is the criteria for a good pass-by? Maybe add a "hits" counter? Just
        >> a thought.
        >
        > Not sure what you mean. A pass by the Target happens when the buggy gets
        > within 20 pixels. The target then jumps to somewhere else on the screen.
        >
        > It's rather reminiscent of the way navigation works in Bamzooki
        > http://www.bbc.co.uk/cbbc/bamzooki/
        >
        > Bamzooki is intriguing for those of us who are interested in robot
        > user-interfaces (i.e. just me AFAIK), It's meant for small children to be
        > able to create legged robots and then to have them navigate. The interesting
        > thing about the user-interface for describing gaits is that it doesn't
        > exist. A child can stick random legs on and the program will steer the
        > resulting robot towards successive waypoints by walking harder on one side.
        > I think the program knows how to "walk" by recognising the class of legs
        > used but I don't know how it coordinates the phases of legs on different
        > segments.
        >
        > Peter
        >
        >
        >
        > ------------------------------------
        >
        > Visit the SRS Website at http://www.seattlerobotics.orgYahoo! Groups Links
        >
        >
        >
        >
      • Peter Balch
        From: KM6VV ... Please do try your own algorithms. I still don t feel I understand why dpa s version doesn t sideswipe trees while mine does. I don t really
        Message 3 of 23 , Jan 2, 2012
        View Source
        • 0 Attachment
          From: KM6VV
          > Interesting simulation!

          Please do try your own algorithms.

          I still don't feel I understand why dpa's version doesn't sideswipe trees
          while mine does. I don't really believe his PID limits angular acceleration
          as much I had to.

          As Randy says, a PID achieves fastest possible closure between target
          setting and actual output. I'm sure that jBot has a faster angular
          acceleration than 0.5 rad/sec/sec.

          Plus, I ought to try dpa's algorithms for switching to/from wall following.

          > You must have a "simulation engine" or similar to write all your
          > simulations. C language, I presume?

          A "simulation engine"? I wish.

          I write them all from scratch in Delphi. I'm one of those weirdos who
          believes they can write better, faster, more reliable code, more quickly in
          Delphi than in C/C++/Java. I've managed to make a few other converts but it
          does have it's disadvantages to be the only person marching in step. Sigh.

          It would be nice to have a "simulation engine" but they're all sufficiently
          different that it's always easier to start again. Yet they're all
          sufficiently similar that I find myself writing the same code over and over.
          In the case of Buggy.exe, I ought to have used the nicer
          compiler/interpreter I have squirrelled away somewhere but I couldn't find
          it and, once again, wrote one from scratch.

          Peter
        • KM6VV
          Hi Peter, Delphi? Been a while since I heard that name! As I recall it s similar to Pascal. I played a little with UCSB Pascal (8 floppy), but after I
          Message 4 of 23 , Jan 2, 2012
          View Source
          • 0 Attachment
            Hi Peter,

            Delphi? Been a while since I heard that name! As I recall it's similar
            to Pascal. I played a little with UCSB Pascal (8" floppy), but after I
            learned C on UNIX, I didn't do much with it. There is a CNC controller
            program with source available, TurboCNC, which causes me to read Pascal
            once and a while, but that's about it. C works for my needs.

            When exactly does DPA switch back and forth from wall following? When
            encountering an obstacle? There must be some sort of comparison between
            target vector strength and obstacle vector strength? Or maybe after the
            target is "in the clear" from the obstacle. That will take a bit more
            thought. Interesting problem!

            Surly there are modules that you can re-use! When I was doing my CNC
            controller program, I already had a text-based GUI (TUI?), and I used it
            for many programs. About all the simulation I ever did was to draw the
            tool path on a grid in the controller program.

            Alan KM6VV

            On 1/2/2012 2:13 AM, Peter Balch wrote:
            > From: KM6VV
            >> Interesting simulation!
            >
            > Please do try your own algorithms.
            >
            > I still don't feel I understand why dpa's version doesn't sideswipe trees
            > while mine does. I don't really believe his PID limits angular acceleration
            > as much I had to.
            >
            > As Randy says, a PID achieves fastest possible closure between target
            > setting and actual output. I'm sure that jBot has a faster angular
            > acceleration than 0.5 rad/sec/sec.
            >
            > Plus, I ought to try dpa's algorithms for switching to/from wall following.
            >
            >> You must have a "simulation engine" or similar to write all your
            >> simulations. C language, I presume?
            >
            > A "simulation engine"? I wish.
            >
            > I write them all from scratch in Delphi. I'm one of those weirdos who
            > believes they can write better, faster, more reliable code, more quickly in
            > Delphi than in C/C++/Java. I've managed to make a few other converts but it
            > does have it's disadvantages to be the only person marching in step. Sigh.
            >
            > It would be nice to have a "simulation engine" but they're all sufficiently
            > different that it's always easier to start again. Yet they're all
            > sufficiently similar that I find myself writing the same code over and over.
            > In the case of Buggy.exe, I ought to have used the nicer
            > compiler/interpreter I have squirrelled away somewhere but I couldn't find
            > it and, once again, wrote one from scratch.
            >
            > Peter
            >
            >
          • Peter Balch
            Alan ... He says: jBot in its current enlightenment attempts to solve this problem by switching between waypoint navigation mode and perimeter following mode.
            Message 5 of 23 , Jan 3, 2012
            View Source
            • 0 Attachment
              Alan

              > When exactly does DPA switch back and forth from wall following?

              He says:

              jBot in its current enlightenment attempts to solve this problem by
              switching between waypoint navigation mode and perimeter following mode.
              When it "determines" that it is in a cul de sac, it switches to a perimeter
              or wall-following mode, and continues in that mode until it "determines"
              that its path to the next waypoint is no longer blocked, at which time it
              returns to waypoint navigation mode.

              As might be obvious, the big problem here is how the robot "determines" when
              to switch between the two modes. I am still working on this, but the current
              method is quite simple. The robot switches on wall-following when/if it
              finds itself heading directly away from the target waypoint. And it switches
              back to waypoint mode when/if it finds itself heading directly toward the
              target waypoint.

              Presumably, "directly toward" is within 20deg of the target heading or
              somesuch.

              Peter
            • Alan
              OK, I can see how that would work. And probably simple enough to model. I m drawn towards a solution that uses a force-type mapping of the important
              Message 6 of 23 , Jan 3, 2012
              View Source
              • 0 Attachment
                OK, I can see how that would work. And probably simple enough to model.

                I'm "drawn" towards a solution that uses a force-type mapping of the
                important elements effecting navigation, something I know I've seen before
                (but don't remember where). Some sort of vector attraction/repulsion model,
                based on something like magnetic attraction. The solution is then "pulled"
                in the proper way to continue towards the target, and avoid the
                obstructions.

                Of course, I'm still working with a much simpler model, only "seeking"
                either the object I want to move, or the goal I want to deposit the object
                in.

                Alan KM6VV

                > -----Original Message-----
                > On Behalf Of Peter Balch
                >
                > Alan
                >
                > > When exactly does DPA switch back and forth from wall following?
                >
                > He says:
                >
                > jBot in its current enlightenment attempts to solve this problem by
                > switching between waypoint navigation mode and perimeter following
                > mode.
                > When it "determines" that it is in a cul de sac, it switches to a
                perimeter
                > or wall-following mode, and continues in that mode until it "determines"
                > that its path to the next waypoint is no longer blocked, at which time it
                > returns to waypoint navigation mode.
                >
                > As might be obvious, the big problem here is how the robot "determines"
                > when
                > to switch between the two modes. I am still working on this, but the
                current
                > method is quite simple. The robot switches on wall-following when/if it
                > finds itself heading directly away from the target waypoint. And it
                switches
                > back to waypoint mode when/if it finds itself heading directly toward the
                > target waypoint.
                >
                > Presumably, "directly toward" is within 20deg of the target heading or
                > somesuch.
                >
                > Peter
              • spiked_spam
                I don t know if this was mentioned, but worth a read; http://opensteer.sourceforge.net/ Also similar ideas applied to flocking; http://www.red3d.com/cwr/boids/
                Message 7 of 23 , Jan 4, 2012
                View Source
                • 0 Attachment
                  I don't know if this was mentioned, but worth a read;

                  http://opensteer.sourceforge.net/

                  Also similar ideas applied to flocking;

                  http://www.red3d.com/cwr/boids/
                • Xandon Frogget
                  dpa, I have several question for you. I tried to break them down into simple Yes or No questions to save you time should you get a chance and choose to
                  Message 8 of 23 , Jan 15, 2012
                  View Source
                  • 0 Attachment
                    dpa,
                    I have several question for you. I tried to break them down into simple "Yes or No" questions to save you time should you get a chance and choose to answer them.
                    On JBot are the 3 wheels on each side in sync?
                    Are the 2 center wheels on Jbot lower then the outer 4, or are they all level?

                    Looking at the photo's and video I see 2 motors and can almost make out a belt or chain. So I am suspecting they are in sync. The reason I ask is, that I was considering the difference between your JBot and the Wild Thumper 6 wheel chassis.
                    There are 2 problems I have noticed with odometry on the Wild Thumper chassis. 
                    First: since there are 3 motors on each side running in parallel, attaching encoders is a bit difficult to obtain accurate odometry. Which wheel would you place them on? (rhetorical) It seems like you would put them on the center wheels since they are actually slightly lower and have the highest tendency to map correctly with the ground. This seems logical except for the second problem.
                    Second: many times while running it in the grass I have noticed the wheels becoming stuck or stall due to friction on a turn or a slick grass spot and all three wheels turning at different rates. Without switching to six independent motor control channels I can't see any way to attach wheel encoders that would provide accurate odometry, even if I did it seems like it would require an encoder for each wheel, which still makes for problems if some of the wheels are slipping. 
                    The only simple solution I could come up with was to attach a trailing free spinning wheel that meters distance and didn't have the ability to slip.

                    I can see how both of these problems could be overcome with the 3 wheels being driven in sync by 2 motors, and only having to use a wheel encoder on each motor. It seems that as long as one wheel on each side is always in contact and step with the ground that this would work well. This brings about the next obvious question. Are you able to compensate for wheel slippage with the PID? If so to what degree?
                    I noticed in the video "Jbot getting unstuck" it experiences a lot of wheel slippage. Do you lose a lot of location accuracy in such hang ups? If so is that where you bring in the GPS, or does it constantly do comparisons? As I am in the early stages working on my wheel encoders I am trying to fully understand the PID and sensor integration.

                    I didn't notice any picture of JBot on grass. Have you run Jbot on the grass much? How does he perform? Here in seattle it is common to have moist and wet grass and I have to do forward rolling turns. The tightest circle I have been able to get with consistency on grass has been about an 8 foot diameter.
                    I am actually using a different chassis to test my odometry as I build it, but I have the wild thumper and wanted to make sure I wasn't discrediting it too soon. If I am able to get accurate odometry on my other robot and I feel comfortable with it I may still try it on the Wild Thumper to test.

                    thanks for any help you can give.
                    -Xandon


                    On Dec 29, 2011, at 9:52 PM, dpa_io wrote:

                     



                    Peter & Michael,

                    Sorry to take so long to respond, but I think Michael has hit on the right answer. And Alan. The PID controllers for each wheel on these robots have slew rate limiters on their inputs. Basically that limits how fast the input can change, and so affects both rotational and translational velocity. I think that and the PID tuning itself are responsible for the behavior blending that you are describing. Interesting.

                    best regards,
                    -dpa

                    --- In SeattleRobotics@yahoogroups.com, "Peter Balch" <peterbalch@...> wrote:
                    >
                    > Michael
                    >
                    > > Wiggle is reduced with the "acceleration" control by limiting the
                    > > speed change of each motor every loop iteration.
                    >
                    > Aha!
                    >
                    > Is the maximum acceleration artificially limited (e.g. by ramp-up,
                    > ramp-down)? And similarly, is the maximum angular acceleration artificially
                    > limited? (Mine isn't.)
                    >
                    > If the angular acceleration is limited, that would mean that the buggy can't
                    > turn as soon as it loses sight of a tree. So it's less likely to side-swipe
                    > them.
                    >
                    > > Do you have the sensors set up with this same field of view?
                    >
                    > I think so. A 30deg wide "beam" either side of centre. It extends around 3
                    > times the length of the buggy.
                    >
                    > > This simulation tool of yours sounds helpful. Is it home grown or an
                    > > available software package?
                    >
                    > It's a quickie I wrote this evening. I've uploaded it to the group's Files.
                    > It's called Buggy.zip (I hope that's not a reflection of its reliability! -
                    > please tell me of any bugs you find). It hasn't turned up in the "Files"
                    > yet - no doubt it will soon.
                    >
                    > It includes an interpreter for a simple language so you can see the
                    > algorithm I've used and modify it as you see fit.
                    >
                    > (I've put in editable "keepout" areas so you can practice what to do in a
                    > dead-end but the current algorithm doesn't do anything sensible like
                    > wall-following. Similarly it doesn't do a ballistic "escape" when it's
                    > trapped between trees - yet. Maybe someone could add those.)
                    >
                    > Peter
                    >


                  • dpa_io
                    ... ... yes ... level ... yes, timing belts ... seems logical ... J. Borenstien from University of Michigan has a paper online about pulling a little
                    Message 9 of 23 , Jan 15, 2012
                    View Source
                    • 0 Attachment
                      --- In SeattleRobotics@yahoogroups.com, Xandon Frogget <xandon@...> wrote:
                      >
                      > dpa,
                      <snip>

                      > On JBot are the 3 wheels on each side in sync?

                      yes

                      > Are the 2 center wheels on Jbot lower then the outer 4, or are they all level?

                      level


                      > Looking at the photo's and video I see 2 motors and can almost make
                      > out a belt or chain.

                      yes, timing belts

                      > So I am suspecting they are in sync. The reason I
                      > ask is, that I was considering the difference between your JBot and
                      > the Wild Thumper 6 wheel chassis.
                      > http://www.pololu.com/catalog/product/1561
                      > There are 2 problems I have noticed with odometry on the Wild Thumper
                      > chassis.
                      > First: since there are 3 motors on each side running in parallel,
                      > attaching encoders is a bit difficult to obtain accurate odometry.
                      > Which wheel would you place them on? (rhetorical) It seems like you
                      > would put them on the center wheels since they are actually slightly
                      > lower and have the highest tendency to map correctly with the ground.
                      > This seems logical except for the second problem.

                      seems logical


                      > Second: many times while running it in the grass I have noticed the
                      > wheels becoming stuck or stall due to friction on a turn or a slick
                      > grass spot and all three wheels turning at different rates. Without
                      > switching to six independent motor control channels I can't see any
                      > way to attach wheel encoders that would provide accurate odometry,
                      > even if I did it seems like it would require an encoder for each
                      > wheel, which still makes for problems if some of the wheels are
                      > slipping.
                      > The only simple solution I could come up with was to attach a trailing
                      > free spinning wheel that meters distance and didn't have the ability
                      > to slip.

                      J. Borenstien from University of Michigan has a paper online about pulling a little trailer behind a tank to do accurate odometry. I can't find the link at the moment, but he seemed to get it to work pretty well.

                      >
                      > I can see how both of these problems could be overcome with the 3
                      > wheels being driven in sync by 2 motors, and only having to use a
                      > wheel encoder on each motor. It seems that as long as one wheel on
                      > each side is always in contact and step with the ground that this
                      > would work well. This brings about the next obvious question. Are you
                      > able to compensate for wheel slippage with the PID? If so to what
                      > degree?
                      > http://www.geology.smu.edu/~dpa-www/robo/jbot/
                      > I noticed in the video "Jbot getting unstuck" it experiences a lot of
                      > wheel slippage. Do you lose a lot of location accuracy in such hang
                      > ups? If so is that where you bring in the GPS, or does it constantly
                      > do comparisons? As I am in the early stages working on my wheel
                      > encoders I am trying to fully understand the PID and sensor integration.


                      This is not a yes or no question! :) The main error that happens with wheel slippage in odometry measurements is the error in theta, the robot's heading. The error in distance traveled is not very significant, but the error in heading throws everything else off.

                      So if you can correct the error in theta, the odometry is much more reliable.

                      jBot does that using an inertial measurement unit to derive theta, rather than deriving it from the wheels, which provide the distance traveled. So the theta value never drifts when the wheels slip.

                      For the SR04 robot, it can use it's stereo sonar to square up on the wall from time to time to correct drift in theta. The Lego robot doesn't do any correction, and it still works pretty well. Getting that level of behavior up and running is probably a good place to start.

                      > I didn't notice any picture of JBot on grass. Have you run Jbot on the
                      > grass much? How does he perform? Here in seattle it is common to have
                      > moist and wet grass and I have to do forward rolling turns. The
                      > tightest circle I have been able to get with consistency on grass has
                      > been about an 8 foot diameter.

                      jBot on grass:

                      <http://www.geology.smu.edu/~dpa-www/robo/jbot/jbot_sq01.mpg>
                      <http://www.geology.smu.edu/dpa-www/robo/jbot/jbot2/jbot_ti2.mpg>


                      > I am actually using a different chassis to test my odometry as I build
                      > it, but I have the wild thumper and wanted to make sure I wasn't
                      > discrediting it too soon. If I am able to get accurate odometry on my
                      > other robot and I feel comfortable with it I may still try it on the
                      > Wild Thumper to test.

                      You might just put encoders on the center two wheels and see how well it works. Nothing like a little empirical data! The trailer might not be needed.

                      best,
                      dpa
                    • David Buckley
                      Borensteins paper is umbmark.pdf from 1994 http://www.google.co.uk/search?rlz=1C1CHIK_en-GBGB436GB436&sourceid=chrome&ie=UTF-8&q=umbmark.pdf =
                      Message 10 of 23 , Jan 15, 2012
                      View Source
                      • 0 Attachment
                        Borensteins paper is umbmark.pdf from 1994
                        =
                        ie
                         
                        DAvid
                         
                        ----- Original Message -----
                        From: dpa_io
                        Sent: Monday, January 16, 2012 12:01 AM
                        Subject: [SeattleRobotics] Re: Accurate odometry

                         



                        --- In SeattleRobotics@yahoogroups.com, Xandon Frogget <xandon@...> wrote:
                        >
                        > dpa,
                        <snip>

                        > On JBot are the 3 wheels on each side in sync?

                        yes

                        > Are the 2 center wheels on Jbot lower then the outer 4, or are they all level?

                        level

                        > Looking at the photo's and video I see 2 motors and can almost make
                        > out a belt or chain.

                        yes, timing belts

                        > So I am suspecting they are in sync. The reason I
                        > ask is, that I was considering the difference between your JBot and
                        > the Wild Thumper 6 wheel chassis.
                        > http://www.pololu.com/catalog/product/1561
                        > There are 2 problems I have noticed with odometry on the Wild Thumper
                        > chassis.
                        > First: since there are 3 motors on each side running in parallel,
                        > attaching encoders is a bit difficult to obtain accurate odometry.
                        > Which wheel would you place them on? (rhetorical) It seems like you
                        > would put them on the center wheels since they are actually slightly
                        > lower and have the highest tendency to map correctly with the ground.
                        > This seems logical except for the second problem.

                        seems logical

                        > Second: many times while running it in the grass I have noticed the
                        > wheels becoming stuck or stall due to friction on a turn or a slick
                        > grass spot and all three wheels turning at different rates. Without
                        > switching to six independent motor control channels I can't see any
                        > way to attach wheel encoders that would provide accurate odometry,
                        > even if I did it seems like it would require an encoder for each
                        > wheel, which still makes for problems if some of the wheels are
                        > slipping.
                        > The only simple solution I could come up with was to attach a trailing
                        > free spinning wheel that meters distance and didn't have the ability
                        > to slip.

                        J. Borenstien from University of Michigan has a paper online about pulling a little trailer behind a tank to do accurate odometry. I can't find the link at the moment, but he seemed to get it to work pretty well.

                        >
                        > I can see how both of these problems could be overcome with the 3
                        > wheels being driven in sync by 2 motors, and only having to use a
                        > wheel encoder on each motor. It seems that as long as one wheel on
                        > each side is always in contact and step with the ground that this
                        > would work well. This brings about the next obvious question. Are you
                        > able to compensate for wheel slippage with the PID? If so to what
                        > degree?
                        > http://www.geology.smu.edu/~dpa-www/robo/jbot/
                        > I noticed in the video "Jbot getting unstuck" it experiences a lot of
                        > wheel slippage. Do you lose a lot of location accuracy in such hang
                        > ups? If so is that where you bring in the GPS, or does it constantly
                        > do comparisons? As I am in the early stages working on my wheel
                        > encoders I am trying to fully understand the PID and sensor integration.

                        This is not a yes or no question! :) The main error that happens with wheel slippage in odometry measurements is the error in theta, the robot's heading. The error in distance traveled is not very significant, but the error in heading throws everything else off.

                        So if you can correct the error in theta, the odometry is much more reliable.

                        jBot does that using an inertial measurement unit to derive theta, rather than deriving it from the wheels, which provide the distance traveled. So the theta value never drifts when the wheels slip.

                        For the SR04 robot, it can use it's stereo sonar to square up on the wall from time to time to correct drift in theta. The Lego robot doesn't do any correction, and it still works pretty well. Getting that level of behavior up and running is probably a good place to start.

                        > I didn't notice any picture of JBot on grass. Have you run Jbot on the
                        > grass much? How does he perform? Here in seattle it is common to have
                        > moist and wet grass and I have to do forward rolling turns. The
                        > tightest circle I have been able to get with consistency on grass has
                        > been about an 8 foot diameter.

                        jBot on grass:

                        <http://www.geology.smu.edu/~dpa-www/robo/jbot/jbot_sq01.mpg>
                        <http://www.geology.smu.edu/dpa-www/robo/jbot/jbot2/jbot_ti2.mpg>

                        > I am actually using a different chassis to test my odometry as I build
                        > it, but I have the wild thumper and wanted to make sure I wasn't
                        > discrediting it too soon. If I am able to get accurate odometry on my
                        > other robot and I feel comfortable with it I may still try it on the
                        > Wild Thumper to test.

                        You might just put encoders on the center two wheels and see how well it works. Nothing like a little empirical data! The trailer might not be needed.

                        best,
                        dpa

                      • Xandon Frogget
                        ... Is that because the recovery and unstick routines balance out to zero distance by moving forward and then back the same amount, or spinning in position? So
                        Message 11 of 23 , Jan 15, 2012
                        View Source
                        • 0 Attachment

                          On Jan 15, 2012, at 4:01 PM, dpa_io wrote:

                          he error in distance traveled is not very significant, but the error in heading throws everything else off.

                          Is that because the recovery and unstick routines balance out to zero distance by moving forward and then back the same amount, or spinning in position? So any distance error would generally only be accumulated from drift or lack of actual movement over the ground between the time it gets stuck and realizes it, and/or distance traveled in a recovery behavior that  was not balanced by movement in the opposite direction of the same recovery movement?

                          -Xandon
                        • dpa_io
                          Part of it is the errors canceling out, as you observe. But mostly it is because the errors in distance traveled are just not very significant, down in the
                          Message 12 of 23 , Jan 15, 2012
                          View Source
                          • 0 Attachment
                            Part of it is the errors canceling out, as you observe. But mostly it is because the errors in distance traveled are just not very significant, down in the noise of the robot's performance. That's the source of the +/- 5 feet error in a 1000 foot run for jBot. For a cartoon description of why that is, check out:

                            <http://geology.heroy.smu.edu/~dpa-www/robo/Encoder/imu_odo/#sec3>

                            and Borenstein has a more rigorous description of all this in one of the appendices of the UMBMark paper.

                            -dpa


                            --- In SeattleRobotics@yahoogroups.com, Xandon Frogget <xandon@...> wrote:
                            >
                            >
                            > On Jan 15, 2012, at 4:01 PM, dpa_io wrote:
                            >
                            > > he error in distance traveled is not very significant, but the error
                            > > in heading throws everything else off.
                            >
                            > Is that because the recovery and unstick routines balance out to zero
                            > distance by moving forward and then back the same amount, or spinning
                            > in position? So any distance error would generally only be accumulated
                            > from drift or lack of actual movement over the ground between the time
                            > it gets stuck and realizes it, and/or distance traveled in a recovery
                            > behavior that was not balanced by movement in the opposite direction
                            > of the same recovery movement?
                            >
                            > -Xandon
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.