Shop OBEX P1 Docs P2 Docs Learn Events
Compass Accuracy & Dead Reckoning — Parallax Forums

Compass Accuracy & Dead Reckoning

ercoerco Posts: 20,256
edited 2011-02-09 17:09 in Robotics
There are several current posts in the Sensor forum regarding compass accuracy or lack thereof. Lots of factors, including the unit's particular installation, latitude, etc, will contribute to errors. But if the repeatability is decent, anyone with patience can make their own calibration table, which should improve accuracy. Even a Stamp can do SIN & COSINE calculations (albeit with integer math). If you have a robot with wheel encoders and a decent compass calibration, what overall accuracy might be achieved when dead reckoning? That is, drive from X1, Y1 to X2, Y2,

Better yet, let's say you start from a known position & orientation called HOME. Then the robot drives an irregular pattern, either from user IR control or random wandering & object avoidance. All the while, it is keeping track of its position with trigonometry. After a few maneuvers, the robot is commanded to go directly HOME, without simply reversing all the steps accrued thus far. If the encoder units are small and the wheels don't slip much (big if), it should be able to calculate a direct vector to get it close.

Anybody experiment with this much yet? I have a nice household odometry platform (Retrobot) and this may be my next adventure, but I haven't experimented with compass sensors yet. The S2 might be a good platform too. If you have any compass experiences to relate, please chime in here!

Comments

  • FranklinFranklin Posts: 4,747
    edited 2011-01-19 18:47
    erco, if you haven't seen this you will be amazed http://www.geology.smu.edu/~dpa-www/robo/jbot/jbot_hatrick2_2.mpg
  • Martin_HMartin_H Posts: 4,051
    edited 2011-01-19 19:21
    That was an awesome video!

    I have a compass sensor for one of my robots. I haven't bothered to align it, but it is still accurate enough to get a rough heading. An odometery experiment like Erco described has been on my to do list, but I haven't gotten around to it yet.
  • ercoerco Posts: 20,256
    edited 2011-01-19 20:13
    Very good, Franklin! I suspect that used a lot more than a compass, probably a GPS antenna in that mast, huh? Simple dead reckoning in bumpy outdoor terrain like that would cause big problems! I'm talking strictly indoors on flat floors.
  • FranklinFranklin Posts: 4,747
    edited 2011-01-19 20:45
    I suspect that used a lot more than a compass,
    Yes, there is more on the page about that robot and here is a link to all his robots.http://www.geology.smu.edu/~dpa-www/myrobots.html
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-01-20 00:20
    There's several compass related programs that I wrote for Penguin robot. Downloads here. It uses the on board stock compass. Take a look at the radio program. Accuracy depends on the accuracy of alignment. Also look at some code in the Penguin Superhero section for another compass app.

    http://www.p-robot.com/index.php/penguin-superhero.html
  • John AbshierJohn Abshier Posts: 1,116
    edited 2011-01-20 08:12
    I have seen that robot in person and it is amazing. It mostly uses dead reckoning and only uses GPS if dead reckoning and GPS differ by a significant amount. But heading/direction is obtained from an $1,500 IMU not a simple compass. Distance is obtained from encoders on the drive motors. If I put any value to my time, it would have been cheaper just to by that IMU. I am still trying to get a resonably accurate heading that works on non-level areas.

    John Abshier
  • ercoerco Posts: 20,256
    edited 2011-01-20 08:51
    @Franklin: Good info on that Journey robot, thanks for the links!

    @Humanoido: Everything I read about compass modules say that perfectly level is critical. I love the Penguin, but don't its wild tilt/stride gyrations limit the accuracy you can expect out of it?

    @John: I'd love a $1500 IMU too, but I have my twins' diapers and future college tuitions to pay for... :) Hey, I'm all about minimalism and reinventing the wheel. So I'm all over that HMC6352 Compass Module... as soon as it goes on sale!

    @Martin_H: Dust off your compass module and let's dive in!

    @Parallax: The S3 will need a built-in compass to complement its great encoder ability!
  • Martin_HMartin_H Posts: 4,051
    edited 2011-01-20 20:03
    @Erco consider it dusted.
  • ercoerco Posts: 20,256
    edited 2011-01-21 08:16
    Suddenly BOTH compass modules are out of stock at Parallax! Someone is foiling my nefarious plans AGAIN!

    My Kingdom for an HMC6352!
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-21 19:04
    I've also read compasses are very sensitive to tilt. If you're using your robot on nice flat floors then they should work. But if you want to go off road you want something that can compensate for tilt.

    The way I want to try to overcome the tilt problem is by using a 3-axis magnetometer (pretty cool word). I have a MicroMag, I purchased from SparkFun a while ago. I haven't done much more than hook it up the Propeller to make sure I could interface with it. I'll need to dust it off and start playing too.

    I installed a couple of encoders on one of the Roboni-I robots I purchased from Woot a while back. Maybe it would make a good dead reckoning bot.

    Duane
  • ercoerco Posts: 20,256
    edited 2011-01-21 19:29
    Duane: Good to have you on board, soldier! But doesn't that Roboni "gerbil" a lot (swing)? That might be counter-productive for keeping level for a compass level, right? :)
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-21 20:17
    erco,

    Ah, yes, the old Roboni swings. But not my new and improved, Propeller powered Roboni.

    The original controls for each motor where either all on or completely off. With the Propeller controlling it, I can smooth out the starts and stops as much as I'd like. I now have proportional steering and it travel a lot faster too. The original robot was pretty well made. It was surprising they didn't have proportional control. I'll have to make a video of my hacked version to show you how much better it behaves now.

    The original had bi-colored LEDs. I added tri-colored LEDs to mine with some pretty cool patterns (if I do say so myself). I'm pretty sure cool LEDs are important features in a dead reckoning robot. I'll ask my wife to video me demonstrating it tomorrow.

    Duane
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-01-24 18:43
    erco wrote: »
    @Humanoido: Everything I read about compass modules say that perfectly level is critical. I love the Penguin, but don't its wild tilt/stride gyrations limit the accuracy you can expect out of it?
    The compass on the Penguin robot is in the X-plane. The radio program and additional programs to which I referred, all take compass reading when Penguin is flat-footed on a level surface, like a table. So you would not take compass readings when tilting and striding. You could try taking readings in between the tilt and stride when Penguin is level but I have not explored this option. The accuracy is so good, if you run the Penguin Superhero programs, it can be used as a compass to get you out of the woods if you become lost. Also accuracy is enough even when Penguin is hand-held. If you want fractional or one degree accuracy, that may be another issue.
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-01-24 18:47
    Humanoid robots couple a compass with an accelerometer. Even wheeled robots may end up on inclined surfaces that affect readings. An accelerometer can produce data which ,when conditioned, will produce a more accurate compass reading.
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-01-24 18:51
    In this region of the country, sometimes the GPS signal is not available. However the compass and accelerometer sensors are always available. This could be a big consideration for some robot designs.
  • ercoerco Posts: 20,256
    edited 2011-01-25 15:46
    Even without compass module, I should test the robot's odometry and triangulation accuracy. I'll use the same test I mentioned previously: starting from a known location and orientation, drive in several random maneuvers, then let the robot track directly back to its starting position & orientation.

    Easy to say, hard to do!
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-25 19:41
    erco,
    erco wrote: »
    drive in several random maneuvers, then let the robot track directly back to its starting position & orientation.

    Easy to say, hard to do!
    You're not kidding.

    I rewrote my encoder method in PASM today to make sure it is fast enough not to miss any pulses. I wanted the method the check the motor's direction before counting each pulse to know if the count should increase or decrease based on the direction (I don't have quadrature encoders, just on set of pulses per wheel). I didn't know how to do this using the Propeller's built in counters.

    As I updated my robot's software, I started thinking about all that would be involved in keeping track of the robot's location.

    Lets say, I'm going to drive my robot with a remote control to a second location. How does the robot keep track of where it is? If one encoder is pulsing faster than the other the robot knows it is turning. It then needs to compute the angle and keep track of its new location based on driving at the new angle. I think the angle could be computed without using trig functions but I don't know how to find the new coordinates of the robot's location without using trig (and taking lots of time to compute).

    What if you drive the robot in a series of curved paths to its new location. How frequently does the robot update its angle and location? Can the robot do the math fast enough to keep track of where it is? Can I write a program that does all this? It boggles my mind. I think it's time to do a search for some good algorithms.

    The problem becomes much simpler if the angles the robot can turn are limited. Let's say the robot can only make 90 degree turns. Now it's not so hard. We could even let the robot make turns in increments of 45 degrees and I could probably write a program so the robot would know where it is. But to let the robot drive any which way is beyond me (at least for now).

    Maybe having the robot compute its location 100 times a second (I think the Prop could do this) is enough to accurately determine its location. The computations probably don't need to take place with every encoder pulse so maybe it's not as bad as I first thought. I still think this is going to be hard to do.

    I'll start looking through some robot ebooks I have to see if I can find any good ideas.

    Anyone else know how to do this? (I'm pretty sure the answer is yes.)

    Duane
  • ercoerco Posts: 20,256
    edited 2011-01-26 07:29
    Duane: Good info on encoders and navigation calcs at http://www.parallax.com/Portals/0/Downloads/docs/prod/datast/ApplyEncoder.pdf by our phantastic phorum phriend Phipi. Suggest you check that out!

    BTW, I have some odometry tricks up my sleeve we can discuss. Check my bot's dead reckoning (on record & playback) at http://www.youtube.com/watch?v=PX0IhUqnwrk
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-26 09:30
    erco,

    Okay, I'm impressed! You show it is definitely doable.

    Phil's paper is helpful. I think I understand the theory okay. I'll try to make some time to work on this.

    I found that I had some bad wiring inside my bot that I fixed this last weekend. I think my bot is up and running now. (I haven't plugged the motors back in yet, so I'm not sure.) This overhauled Roboni has two main problems. No plywood and no relays.

    That robot I just watched on youtube wasn't controlled with relays was it!?!

    Duane
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-26 09:36
    erco,

    I forgot to mention. I think your estimate of the robot being an inch off after its loop is incorrect. If you go back and look at the beginning, I think you'll see a more accurate estimate is 1/4". Wow!

    (I used the two dots (screws?) in the center of the rear of the robot and tried to line them up with the left most hole in the outlet. They are just about in the same place in both the beginning and the end of the video.)

    Duane
  • ercoerco Posts: 20,256
    edited 2011-01-26 10:53
    Yep, that's my relay and BS2 Retrobot!

    The video is impressive and also easy to misinterpret. The robot very accurately records and plays back whatever path I program into it. As such, it wasn't really homing in on that wall socket or anything else; that was simply the last place I drove it to when recording that path. For my demo, it was convenient to end the same place I started. Its final position had more to do with my driving skill while recording than the bot's ability to retrace its path. What surprised me most was that the robot's orientation was dead-on. It was perfectly square to the wall as it did its final stopping maneuver. Not bad for relays! I favor relays for dynamic braking, critical to dead reckoning.
  • ercoerco Posts: 20,256
    edited 2011-01-27 02:26
    http://forums.parallax.com/showthread.php?129094-24-Tilt-Compensated-Compass-Module
  • Ray0665Ray0665 Posts: 231
    edited 2011-01-30 08:49
    Here is an interesting paper that may be of interest - included more info on the JBOT.

    http://www.seattlerobotics.org/Encoder/200610/article3/IMU%20Odometry,%20by%20David%20Anderson.htm

    Dave Anderson also has a paper on the SR04 robot which describes in detail the navigation and overall design of the SR04
    but I can't find it right now, when I do I'll come bake and update this post.

    Here is another interesting paper on the SR04/JBot
    http://geology.heroy.smu.edu/~dpa-www/robo/subsumption/
  • FranklinFranklin Posts: 4,747
    edited 2011-01-30 13:58
    Here is the link I found, might be the one you are looking for http://www.geology.smu.edu/~dpa-www/robots/sr04/index.html
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-01-30 19:55
    These links are very helpful. Thanks.

    I can see why a compass can be so important.
    IF ACCUMULATED ERRORS IN HEADING CAN BE ELIMINATED
    THEN ACCUMULATED ERRORS IN DISTANCE CAN BE SAFELY IGNORED.

    Now I just need time to work on this.
  • Martin_HMartin_H Posts: 4,051
    edited 2011-02-09 17:09
    So I have run the alignment program for my compass and it seems to have improved it a little bit. The errors from the ideal values weren't all that great to begin with. One thing that really stood out to me is the glaring difference between polar and compass coordinates. Darn those cartographers!

    I've also been reading through Phil's encoder document (http://www.parallax.com/Portals/0/Downloads/docs/prod/datast/ApplyEncoder.pdf). It'd a good read, but takes more than once through to fully get it (at least it did for me). But one thing I was confused about in the sample program are these constants on page 29 and their comments:

    SenseR PIN 10 'Lefthand encoder input.
    SenseL PIN 11 'Righthand encoder input. (MUST be SenseL + 1.)
    MotorR PIN 12 'Lefthand motor output.
    MotorL PIN 13 'Righthand motor output. (MUST be MotorL + 1.)

    The code looks correct, but the comments have the lefts and rights reversed. Later on 33 it's turned around the other way:

    SenseR PIN 10 'Righthand encoder input.
    SenseL PIN 11 'Lefthand encoder input. (MUST be SenseR + 1.)
    MotorR PIN 12 'Righthand motor output.
    MotorL PIN 13 'Lefthand motor output. (MUST be MotorR + 1.)
Sign In or Register to comment.