Compass Accuracy & Dead Reckoning
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!
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
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.
http://www.p-robot.com/index.php/penguin-superhero.html
John Abshier
@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...
@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!
My Kingdom for an HMC6352!
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
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
Easy to say, hard to do!
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
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
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
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
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.
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/
I can see why a compass can be so important.
Now I just need time to work on this.
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.)